The present invention relates to the detection, reporting, and resolution of anomalies in a telecommunications network, and more particularly to the automation of the anomaly handling and resolution procedures that are associated with such a telecommunications network.
A modem telecommunications network is an extremely complex system composed of a plethora of network components. To ensure that the telecommunications network remains in proper working condition, the performance of these various network components is continuously monitored by network monitoring personnel, referred to hereinafter as xe2x80x9cnetwork monitors.xe2x80x9d The network monitors, often remotely located from the telecommunications network, monitor the network by reviewing reports of anomalies generated within the telecommunications network. The collection of systems used to monitor these anomalies is referred to as a network monitoring environment.
In the telecommunications network, alarms are assigned to various network components and sound when anomalies are detected in their respective components. In addition, the sites where the network components are physically located may be equipped with alarms and also may be monitored. Other equipment peripheral to the network may also be equipped with alarms. Each alarm is reported to the network monitors through an electronic message (an alarm report), which provides an indication of a network anomaly. The network monitors use the alarm reports to investigate and resolve the anomaly that generated the alarm.
Monitoring a telecommunications network is a complicated undertaking, especially considering the many components which comprise a typical network. Moreover, in light of the multitude of alarms attached to the network, the network monitors may be inundated periodically with alarm reports due to one or more major anomalies in the network, or even a series of small anomalies arising within a brief timespan. This tremendous volume of alarm reports can overwhelm the network monitors and hamper the process of returning the telecommunications network to proper working condition.
In conventional network monitoring environments, network monitors receive alarm reports from the telecommunications network and then manually process these alarm reports. Processing an alarm report provides an orderly procedure for resolving the anomaly that generated an alarm. The processing of alarm reports to resolve network anomalies typically entails retrieving from paper manuals network parameter information, such as equipment operating characteristics; consulting telephone directories to find telephone numbers for remote network sites; and optionally, completing hard copy telecommunications trouble forms, referred to as trouble tickets or service reports. A network monitor prepares a trouble ticket, also known as a service report, when action by a field engineer appears necessary in order to resolve the anomaly causing an alarm. Field engineers are typically telecommunications personnel who service the telecommunications network (e.g., replacing a faulty transformer at a specific location).
In conventional network monitoring environments, a network monitor prepares a trouble ticket using some type of service management system, for example, a trouble management system (xe2x80x9cTMSxe2x80x9d). Conventional TMSs are separate computer systems from the telecommunications network where the alarm reports are generated. As a result, a network monitor must manually copy the alarm report information to create a trouble ticket in the TMS. In addition, once the trouble ticket is submitted to the TMS, the network monitor receives status update information from the TMS. However, a network monitor may not typically select the type of status update information received from the TMS.
FIG. 1 is a block diagram depicting the logical architecture of a conventional network monitoring environment. The network monitoring environment comprises a telecommunications network 107, a network management system 100, network monitors 104, a TMS 105, and field engineers 106. The telecommunications network 107 consists of various components from electronic equipment, wires, and transformers to sites in which this equipment is housed. The network management system 100 typically includes an alarm handling function module (xe2x80x9cFMxe2x80x9d) 101, an alarm handling presentation module (xe2x80x9cPMxe2x80x9d) 102, and an iconic map PM 103. The network management system 100 receives alarm reports generated by components of the telecommunications network 107 due to an anomaly detected within a component. Network monitors 104 receive the alarm reports from the alarm handling PM 102 and initiate the process of correcting the anomalies that generated the alarm reports. The network monitors 104 may use the information from the alarm reports to create trouble tickets using the TMS 105. The TMS 105 provides a system for dispatching field engineers 106 to the physical location of a reported anomaly based upon the created trouble tickets. The field engineers 106 investigate and correct the reported anomaly.
In a typical operation, a network monitor, such as network monitor 104, is assigned to monitor the telecommunications network at a particular location in the network or to monitor a particular type of network component. The network monitor typically uses a computer workstation to perform the monitoring procedures. In presently available network monitoring environments, when a network management system, such as a network management system 100, receives an alarm report, it is generally assigned manually to the proper network monitor (by routing it to the appropriate workstation). Having received the alarm report, the network monitor may first attempt to verify the anomaly represented by the alarm report, or the network monitor may attempt to resolve the anomaly by telephoning personnel located at the site from which the alarm originated. For example, a network monitor may receive an alarm report indicating that a door has been opened at a remote network station by someone who did not enter a proper authorization code prior to entering. In response to such an alarm, the network monitor typically consults a paper telephone book of network site personnel to locate the telephone number of the corresponding site manager or a subordinate. The network monitor then telephones the site and verbally informs appropriate personnel that the open door alarm has occurred.
On the other hand, the alarm report received by a network monitor may indicate a condition, such as a break in a communications line, which the network monitor cannot resolve and which will ultimately require the attention of a field engineer, such as field engineer 106. In order to bring this alarm to the attention of the field engineering staff, conventional network monitoring environments require the network monitor to manually create a trouble ticket on a TMS, such as TMS 105, and to copy the relevant information manually from the alarm report into the trouble ticket for processing by a TMS. To complete the trouble ticket properly, the network monitor typically adds additional information, some of which the network monitor generally finds by referencing paper manuals that contain, for example, site, topology, or equipment information.
A network monitor may often determine that multiple alarm reports received from the telecommunications network can be grouped together to facilitate processing. For example, the network monitor may believe that the alarm reports have a common source or are otherwise related. The selection of either a single alarm report or the grouping of multiple alarm reports together to facilitate processing is known as creating an xe2x80x9ceventxe2x80x9d to those skilled in art. An alarm typically represents the mere appearance of an anomaly within a particular network component. An event, on the other hand, represents the logical grouping of multiple network anomalies, or apparent aiomalies. For example, if a tree falls over during a thunderstorm and cuts through a major telecommunications line, at least one, and perhaps dozens, of alarms will sound. However, all of these alarms can be logically grouped together into one event, the event being the single cut in a line caused by a thunderstorm.
Events are documented in forms known as event reports. Thus, while the network monitor collects alarm reports, the network monitor actually processes and resolves event reports. In a conventional network monitoring environment, the network monitor will append the corresponding (component) alarm reports to an event report. The event report itself may be annotated with other useful information by the network monitor.
The ease in which alarm reports can be processed by network monitors has improved somewhat by the recent development of network management systems. A network management system, such as network management system 100, typically resides between a network monitor and the network components and collects, stores, and manages the alarm reports produced by the network components and presents the alarm reports to the network monitors. The network management system provides object models for storing and distributing the alarm reports received from the telecommunications network. For example, alarm handling FM 101 collects and stores alarm reports as objects; alarm handling PM 102 displays alarm reports to a network monitor, and iconic map PM 103 displays in graphical form the telecommunication network with alarm locations superimposed over the network map.
An example of an existing network management system is the Telecommunications Management Information Platform (xe2x80x9cTeMIPxe2x80x9d), which was built by Digital Equipment Corporation (xe2x80x9cDECxe2x80x9d). TeMIP collects, stores, and manages network alarm reports as data objects. TeMIP also provides a presentation manager for presenting to a network monitor all alarm reports collected from the network. However, no presently available network management system, including TeMIP, provides functionality for automating a network monitor""s activities or provides an adequate bridge between the telecommunications network and the TMS 105. Moreover, presently available network management systems provide only limited information on each alarm report. Many procedures must still be done manually by the network monitors.
In summary, presently available network monitoring environments provide only rudimentary support for a network monitor""s activities. None provide adequate support for the network monitor""s trouble response duties, such as resolving alarm reports manually or by issuing a trouble ticket. For example, the proper response period for certain critical alarms can be as small as a few seconds. Current network monitoring environments have not sufficiently reduced the response period to achieve this level of responsiveness. As discussed above, current network monitoring environments are very limited in the features they provide for network monitors, and such network monitoring environments cannot be easily tailored to accommodate the workflow of network monitors.
Embodiments of the present invention provide methods and systems for automating the dissemination and processing of alarm reports received from a telecommunications network. Alarm reports, which correspond to alarms generated by the telecommunications network, are provided by a network management system to network monitors. A network monitor can select one or more alarm reports for grouping into an event report. The network monitor can use the event report in resolving the alarm report and can also use the event report to produce a trouble ticket for further processing by a service management system, such as a trouble management system (xe2x80x9cTMSxe2x80x9d).
To provide the automated dissemination and processing of alarm reports, embodiments of the present invention provide a network monitoring tool, referred to as an automated workflow system, which automates the workflow of network monitors. The automated workflow system also provides automated event report and trouble ticket handling. For example, a network monitor may select alarm reports and create an event report based on those alarm reports. The network monitor may also optionally create a trouble ticket for that event. The automated workflow system automatically creates the event reports and trouble tickets, incorporates the relevant alarm information, and incorporates other related data. For example, network site and topology information may be incorporated. The automated workflow system may utilize external systems, such as remote databases, to provide the information for the event report or the trouble ticket. Alternatively, the information may be stored within the automated workflow system.
In one embodiment, the automated workflow system provides a set of tools that can be implemented in a network monitoring environment. These tools automate network monitor procedures such as creating events, assigning alarm reports to events, creating trouble tickets against events, assigning trouble tickets to network monitors, tracking trouble tickets, updating alarm report status to indicate which alarm reports have been handled by a trouble ticket, and updating alarm report status to indicate which alarm reports have been cleared by the closing of an event. In addition, feedback loops have also been built into these automation processes to apprise network monitors of developments associated with resolving network-generated alarms.
In a further embodiment, the automated workflow system may automate the functions of a network monitor using rules-based artificial intelligence technology. The artificial intelligence technology may either fully automate the network monitor""s functions or may operate semi-autonomously to support the network monitors.